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1.0 Introduction 

The primary purpose of this study was to develop a standard format 
for the specification of algorithms . While a number of standards exist 
for so-called algorithm specification, (e.g. ACM's Algorithm Policy, 

CACM J4 (1971) 67 G) , in fact those standards are for programs, algorithms 
which have been implemented in a particular language or for a particular 
computer . 

It was desired to have a standard specification from which the algor- 
ithm can be easily implemented and from 'which a prospective user could 
decide within certain limits , whether a given algorithm meets his require- 
ments before actual implementation on his hardware . Alternatively the 
algorithm specification should be able to help the potential user decide 
upon what hardv/are 'would be required to solve his problem. It is clear, 
then, that we wish to keep the specification of the algorithm independent 
of any particular programming language or any computer. While this is 
desirable from the standpoint of the user who is in the process of choosing 
hardware, it is more difficult for the algorithm specification to be written, 
and some information which it is desirable to know cannot be given in 
this generality . 

A number of investigations into methods of specifying algorithms have 
been made, and we will mention some of them briefly. 

D. L. Parnas [ 11] has suggested an algol-like language which is 
designed to convey to the user and the implementer alike exactly that 
information he needs and no more. In addition, the specification is de- 
signed so that it is possible to machine test it for completeness and con- 
sistency. The author notes that the technique has been met with some 
resistance and initial failures, although it "is eventually mastered by 
almost everyone." This writer certainly believes the first part of that 
statement and feels that the information conveyed about what function is 
performed by the algorithm is too sparse. 
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In the examples it is quite unclear what is being done, although 
perhaps this is in line with the stated intent of the author concerning the 
information to be conveyed . The goal of minimal information about the 
structure of connecting modules , and the possibility of machine testing 
for completeness and consistency are certainly desirable and further 
development may yield better methods . 

The specification of algorithms in terms of a set language has been 
treated by several authors, e.g. [4] , [14] . While these abstract 
languages have desirable properties, particularly in terms of precision, 
as Schwartz [14] notes they do not give as clear an explanation of the 
algorithm as a natural language description „ This occurs in an elusive, 
but still real, sense. 

The use of flow charts 1 1 6] and D-charts [1] have been discussed 
also. While flow charts are familiar to nearly everyone, and can be 
used to completely specify the flow of control in the algorithm, some 
important information is suppressed by them. In particular, a flow chart 
can show only one of perhaps many equivalent implementations of an 
algorithm. Possible parallelism and much of the data dependencies are 
obscured . 

Several attempts have been made to develop methods which overcome 
the problems inherent in flow charts . Those methods take the form of 
directed graphs and are generally descendants of Petri nets [5] , [15] . 
The most elegant of these appears to be the data flow language of Dennis 
and Fosseen [ 2] , although a number of earlier versions are included in 
the bibliography. The data flow language has the desirable property of 
showing the fiow of the data and is particularly useful in blocks where 
there are no iteration loops and no branching is required . A partial 
ordering on the sequence of operations is automatically induced, and 
possible parallelism is exposed. In addition, data dependencies are 



clearly shown which is helpful in the partitioning problem, although that 
is not our principal interest. The inclusion of control links in the rep- 
resentation, necessary to show iteration loops and branching, clouds 
the picture considerably. For all but the simplest algorithms, the repre- 
sentation becomes quite clumsy, making it fairly difficult to specify the 
algorithm and more difficult to understand it. At a point where it would 
conceivably be possible for the language to be compiled by a computer, 
it could very well become quite valuable . Studies are being made toward 
a computer which could implement algorithms in this way [ 3] . 

It is recognized that it is desirable to specify algorithms in a non- 
redundant manner, and in a way which is capable of being machine 
processed for completeness and consistency. At this time it is felt that 
there is no method which meets all desirable requirements . Because of 
the distinct sets of persons who would be looking at the specification, in 
particular the prospective user and the implementer, it is almost a 
necessity that the information be somewhat redundant or that the interests 
of one of the two groups be treated more lightly than the other . Addition- 
ally while flow graphs or flow charts sen/e to specify the algorithm for the 
implementer' s purposes, as do the mathematical equations or natural 
language descriptions, the sets of information in those two items serve 
to complement each other to a greater degree than their redundancy de- 
tracts from them . One reason for avoiding redundancy is that it allows the 
possibility of contradictions, which must not be allowed to occur without 
a method of resolving them. Even then it is not a desirable situation. 

Because of the shortcomings of most new methods proposed for al- 
gorithm specification, we have attempted to maintain a somewhat conven- 
tional method of algorithm specification, while incorporating the best 
features of some new ideas . Further development in any of several possible 
directions may lead to new methods more suited to our purposes and we must 
certainly be alert to any such development , 
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2.0 The Format of the Proposed Specification 

The specification of the algorithm will be in two parts, for our 
purposes . Those items in Section 1 will be mainly of interest to the user. 
Section 2 wilL be devoted to information needed by the implementer. After 
implementation, the program documentation will give information concerning 
storage requirements and timing which will be of interest to the user. In 
effect, this documentation will form a Section 3, There will be a differ- 
ent documentation for each implementation (different language or dif- 
ferent computer) . We will not concern ourselves with the exact form of 
the documentation, but it will consist primarily of the exact method of 
communication with the calling program, and memory and timing require- 
ments . The implementation must conform to the specification in Sec- 
tions 1 and 2 with no exceptions or else it cannot be considered to be an 
implementation of that algorithm . 

The description of the various sections in the algorithm specification 
and the information they are to convey follows in Section 2 .1. 

2.1 The Algorithm Specification 

1.0 Background Information and General Description 

This section will contain information about where the algorithm is 
used and a brief description of what the algorithm accomplishes . 

The information given should be sufficient to allow the user to de- 
termine whether the algorithm is of interest to him without giving 
unnecessary details . 

1.1 Other Algorithms Used 

This section will contain a listing of other algorithms used by the 
subject algorithm. 

1.2 Input Values 

This section will contain a description of the values which are 
input to the algorithm. These must be described in terms of units 
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(where required; sometimes the input units needn't be specified 
and output units are the same as input units) , reference lines 
or angles, which direction is positive, and so on. Any assumptions 
concerning the range in which the inputs must lie should be de- 
lineated . This, in conjunction with possible error indications 
(see Section 1.3) will convey to the user the possible need for pre- 
processing of arguments by the calling program. 

1.3 Output Values and Accuracy 

The values which are output from the algorithm are described in 
this section. Information about the accuracy of the output values 
should assume the inputs are exact, even though in the usual instance 
this will not be true. Given in this fashion, though, and given 
information about the accuracy of the input values , one can determine 
limits on the error propogated through the algorithm. When necessary, 
the units, reference lines or angles, positive directions, and other 
data must be specified as they are for input. Possible output values 
include error indications and potential error flags should be fully 
described . 

1 .4 Operation Count 

The precise timing for an algorithm is available only after the 
choice of implementation has been made. However, some useful 
information can be given in terms of the number of operations of 
different type which occur and the number of references to external 
routines (other algorithms) . Thus it will be possible to give the 
user a rough estimate of the execution time in terms of the operations 
required . This estimate will be most accurate when large numbers of 
arithmetic instructions are required for which the time can be esti- 
mated with some accuracy. In other instances the count may be 
highly dependent on the instruction repertoire of the computer, and 
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2 .0 The Format of the Proposed Specification 

The specification of the algorithm will be in two parts, for our 
purposes . Those items in Section 1 will be mainly of interest to the user. 
Section 2 will be devoted to information needed by the implementei . After 
implementation, the program documentation will give information concerning 
storage requirements and timing which will be of interest to the user. 

In effect, this documentation will form a Section 3. There will be a dif- 
ferent documentation for each implementation (different language or 
different computer) . We will not concern ourselves with the exact form of 
the documentation, but it will consist primarily of the exact method of 
communication with the calling program, and memory and timing require- 
ments . The implementation must conform to the specification in Sections 
1 and 2 with no exceptions or else it cannot be considered to be an im- 
plementation of that algorithm. 

The description of the various sections in the algorithm specifica- 
tion and the information they are to convey follows in Section 2 .1 . 

2.1 The Algorithm Specification 

1 .0 Background Information and General Description 

This section will contain information about where the algorithm 
is used and a brief description of what the algorithm accomplishes . 

The information given should be sufficient to allow the user to deter- 
mine whether the algorithm is of interest to him without giving unneces- 
sary details . 

1.1 Other Algorithms Used 

This section will contain a listing of other algorithms used by the 
subject algorithm. 

1.2 Input Values 

This section will contain a description of the values which are 
input to the algorithm. These must be described in terms of units 
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hence only a poor estimate can be given before implementation. 

In any case the estimate will not include overhead and should be 
interpreted in that light. 

1.5 Memory Requirements 

This section, like the previous one, cannot be made very 
precise. In particular, the program length cannot be estimated 
without knowing the instruction repertoire of the computer on 
which the algorithm is implemented. However, this section can 
contain information concerning the number of constants required 
and the number of temporary storage locations required by the al- 
gorithm . 

2 .0 Mathematical and Natural Language Description 

This section gives a full description of the algorithm in terms 
of the mathematic equations, if any, and the necessary natural 
language descriptions necessary to make clear the functions per- 
formed by the algorithm. The definition of each variable should be 
given. For algorithms with many variables a list should be given 
as this would facilitate finding the definitions easily. If possible, 
the range of values which may be taken on by each variable should 
be specified. One must at least specify whether the values taken 
on are integers , real numbers , complex numbers , or logical values . 

2 .1 Flow Diagrams 

The flow diagrams may consist of two types . When the algorithm 
involves iterations or a large number of decisions, a conventional 
flow chart is probably best since in this case the flow of control 
is most important. When only a few decisions are required, or none, 
the use of a process graph is desirable since it exposes many 
features of which the implementer should be aware. 

The type of process graph we generally have in mind is similar 
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to the data flow graph of Dennis and Fosseen [ 2] when there are 
no decisions to be shown. We will briefly discuss the elements 
and structure of the process graph as we intend it to be used. 

The process graph consists of computational blocks,, each 
of which may be as complex (a subalgorithm) or as simple (a single 
operation) as one likes or finds necessary. These blocks are con- 
nected by directed line segments to form a directed graph. The line 
segments show the flow of data through the graph. Input values to 
a computational block are shown as labeled line segments directed 
toward the block . The computations in a block may be performed 
as soon as all input values are available. Outputs from a block are 
shown by labeled line segments directed away from the block. 

Input values which are not output values from another block are in- 
puts to the algorithm, except for constants which are shown arising 
from disks . Output values which are not input values for another 
block are outputs from the algorithm. Process graphs are in many 
w’ays reminiscent of signal flow graphs [8] , although process 
graphs have no feedback and involve more complicated operations . 

A similar type of graph has previously been used to describe com- 
plicated weapon systems, e.g. [8] . In addition to their utility 
in determining data dependencies , a partial ordering of operations , 
and potential parallelism, process graphs can also be utilized to 
determine error bounds for a set of calculations . They are used 
primarily for this purpose, in a slightly different form, by 
McCracken and Dorn [9] . 

We propose that the type of flow diagram provided for a given 
algorithm should be an option of the specification writer. In some 
instances one of the two types, flow chart or process graph, may 
be more appropriate. In other instances it may be useful to include 
both a flow chart and a process graph. This leads to a possible 
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difficulty in that a flow chart yields a complete ordering on the 
operations performed, whereas a process chart ordinarily yields 
only a partial ordering . Some algorithms may be best described 
by a process graph involving computational blocks with decisions 
and iterations imbedded in them. These computational blocks 
might be best described by flow charts . Or the reverse may be 
better in some instances , although the flow of the data would, 
seem to be somewhat obscured by the use of an overall flow chart. 

2.2 Other 

When the algorithm specification is being written it may be 
necessary to make certain assumptions about number representa- 
tion or other details which may vary for some implementations , 
but have no profound effect on the algorithm. In this section such 
variations and their effect on the implementation should be pointed 
out . 

2.3 References 

This section contains a list of all books, reports, journal 
articles and other items which may be referenced for additional 
information . 

3.0 Some Algorithms 

The following examples are intended to illustrate the proposed 
method of algorithm specification. While not all types of algorithms 
are included , among them are purely a computational algorithm , a 
purely manipulative algorithm, and several floating point algorithms 
which involve a number of tests and shifts as well as a few arithmetic 
operations . 
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I. Coordinate Rotation: Airframe to Earth Coordinates 



1.0 Background Information and General Discussion 

The purpose of this algorithm is to convert the coordinates of 
a radar target or other object given in airframe coordinates to earth co- 
ordinates . 

1.1 Other Algorithms Used 

This algorithm uses the sine and cosine algorithms . 

1.2 Input Values 

The input values to this routine are the coordinates of the 
target with respect to the airframe, and the heading, pitch angle, and 
roll angle of the airframe. All input values are real numbers . It is as- 
sumed that the heading, pitch angle, and roll angle are given in degrees . 
The heading, ^ normally lies in the range [ 0 , 360 °] , while the pitch 
angle, 0 and the roll angle, 0 lie in the range [ - 180 ° , 180 ] . No 

error occurs for angles outside this range, A due north heading is zero, 
while easterly headings are positive. Pitch angles are positive nose up, 
and roll angles are positive right wing down. 

1.3 Output Values and Accuracy 

The output values are the earth coordinates of the target with 
respect to the position of the airframe . Output units are the same as 
the input units . The positive directions for the output coordinates are 
north, east, and down, respectively. 

The accuracy of the results depens on the accuracy of the sine/ 
cosine algorithm and could be as large as about 7 or 8 times the error 
in that algorithm, relative to the largest of the airframe coordinates . 

The usual error will be much smaller, perhaps one or two bits compared 
to the largest of the airframe coordinates . 
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1.4 Operation Count 

The algorithm requires six sine/cosine evaluations, 2 6 multipli- 
cations, and 10 additions which should dominate the total execution time. 

1.5 Memory Requirements 

This routine requires about ten temporary storage locations , one 

constant, and locations for any registers that must be saved. 

2 .0 Mathematical and Natural Language Description 

Let x - y - z be a right hand orthogonal coordinate system 
a a a 

associated with the airframe, x is positive forward along the airframe 

a 

center line, y is positive out the right wing, and z is positive 
a a 

downward . Let x , y , and z represent the airframe coordinates of 

a a a 

the target. Let ^ be the airframe heading with respect to true north, 

0 the airframe pitch angle-positive upward, and 0 the airframe roll angle - 
positive right wing down „ Then the target position in earth coordinates is 
given by a rotation of the position in airframe coordinates, represented by 
the matrix multiplication 
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are the north, east, and down components of the earth coordinates, re- 
spectively. The matrix elements are given by 
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2.1 



Flow Diagram 



2.1.1 Process Graph 
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2 .2 Other 
None 

2.3 References 

See Bibliography [ 12] 



II. Coordinate Conversion: Spherical to Cartesian Coordinates 



1. Background Information and General Discussion 

The purpose of this algorithm is to convert the given spherical 
coordinates of a point in three space to the corresponding cartesian co- 
ordinates . 

1.1 Other Algorithms Used 

The sine/cosine algorithm is used by this algorithm. 

1„2 Input Values 

The input values are the spherical coordinates, (p , 0 , e) of a 
given point, which are real numbers . Here D is the distance of the 
point from the pole, or origin, 0 is the angle the radius vector makes 
with the z-axis , and 6 is the angle the projection of the radius vector 
into the x-y plane makes with the x-axis, measured positive counter- 
clockwise . Angles are measured in radians „ 

The figure shows the relationship for a typical point P . 

z 
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1.3 Output Values and Accuracy 

The output values are the x, y, and z coordinates of the given 
point. The units are the same as those of the input P . The error in the 
coordinates, relative to D , would be no more than twice the error in the 
sine/cosine algorithm. 

1.4 Operation Count 

This algorithm requires four sine/cosine evaluations and four 
multiplications . 

1.5 Memory Requirements 

Approximately four locations are required for temporary storage 
plus any locations required for storage of registers . 

2 .0 Mathematical and Natural Language Description 

The equations relating spherical coordinates ( p, 0 , g) and 
cartesian coordinates (x, y, z) are 
x = p sin 0 cos G 

y = p sin 0 cos 0 

Z = p COS 0 o 

p , 0 , and g are real numbers and ordinarily p ^ 0 , 

0^0 s n* and 0 s 0 < 2 tt , although these restrictions are not 

necessary for proper operation of the algorithm. 
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2.1 Flow Diagram 

2.1.1 Process Graph 
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2 .2 Other 
None 

2.3 References 



None 



III. Radar Target Processing 

1.0 Background Information and General Description 

The purpose of the algorithm is to convert the radar outputs of 
range, bearing, and elevation with respect to airframe coordinates to 
earth coordinates . 

1.1 Other Algorithms Used 

The spherical to cartesian coordinate conversion algorithm (II) and 
the coordinate rotation algorithm (I) are used. 

1.2 Input Values 

The input values to the algorithm are the radar outputs of range , 
bearing, and elevation, and the airframe heading, pitch angle, and roll 
angle. All angles are in degrees . Positive directions for the airframe are 
as described in algorithm I. Target bearing is measured from the airframe 
x - z plane, positive clockwise when viewed from above. Elevation is 

cl 8 

positive upward with respect to the airframe x - y plane. 

cl 8 

1.3 Output Values 

The output values are the earth coordinates of the target with 
respect to the airframe position, in northerly, easterly, and downward com- 
ponents . The units are the same as those of the input range . The error 
in the output values is no greater than the sum of the errors in the algor- 
ithms I and II, hence the error is no greater than 8 or 9 times the error in 
the sine/cosine routine. This is the error measured relative to the input 
value of range , In the usual case the error should be about one or two 
bits , relative to the range . 

1 .4 Operation Count 

The algorithm requires two additions and two multiplications for 
argument processing before one transfer to each of the algorithms men- 
tioned in section 1.1. 
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1.5 Memory Requirements 



Two constants are required by the algorithm . 

2 .0 Mathematical and Natural Language Description 

Let x , y , z , be the axes of an orthogonal coordinate sys- 
a a a 

tern associated with the airframe, x is positive forward along the air- 

a 

frame center line, y is positive out the right wing and z is positive 

a a 

downward. Let R be the slant range to the target, F, the target 

s t 

elevation with respect to the x_ - y plane-positive upward, and ^ 

a a t 

the target bearing with respect to the x - z plane-positive clockwise 

a a 

when viewed from above. Then the spherical coordinates of the target 
are (R , 0, Q) , where 0 = 90 + £ and 6 = 90 ° " 4. • 

S L L 

The angles are assumed to be in degrees and are converted to 
radians before entry to the spherical to cartesian coordinate conversion 
algorithm. The airframe coordinates are then converted to earth co- 
ordinates using algorithm I. 
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2.1 Flow Diagram 

2.1.1 Process Graph 




I 
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2.2 Other 
None 

2.3 References 

See Bibliography [12] 
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IV. Floating Point Multiplication 

1 .0 Background Information and General Description 

The purpose of this algorithm is to obtain the product of two 
numbers represented in floating point format on a computer which does 
not have floating point hardware. It is assumed the computer is capable 
of performing fixed point additions and multiplications . 

1.1 Other Algorithms Used 

No other algorithms are used by the floating poing multiply. 

1.2 Input Values 

The input values are the two operands expressed in floating 
point format . 

1.3 Output Values and Accuracy 

The output value is the product of the operands expressed in 
floating point format. The output valve is in normalized form provided 
the input values are in normalized form (no leading zero digits) „ If 
the characteristic of the product exceeds the maximum allowable, an 
overflow is indicated and the characteristic is set to the maximum 
number which can be represented. The result is accurate to + \ in the 
least significant digit of the mantissa . 

1 .4 Operation Count 

The number of operations depends on the instruction repertoire 
of the computer, but will involve one multiplication, one addition, and 
about 15 index incrementation, test, compare, shift, and logical oper- 
ations . 

1.5 Memory Requirements 

The algorithm requires about ten locations for temporary storage 
and constants, depending on how the arguments are transmitted to the 
algorithm . 
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2.0 Mathematical and Natural Language Description 

Let the two operands be represented by A and R . Define A 

m 

and a such that A = A g , where g is the base of the number system 

rrr H 

used by the computer, A is the mantissa, and a is the characteristic „ 

^ — 1 

We assume A is in normalized form that is g <: |A I < 1 or A = 0 „ 
m m a + D m 

B and b are defined analogously. Because AB = A B g the 
m mm 

algorithm multiplies mantissae, adds characteristics, normalizes the 
product of the mantissae, rounds and renormalizes the product of the man- 
tissae. Normalizations are done under the assumption A and B were 
normalized. If A or B are not normalized, then the product may not be 
normalized. If the product of the (unnormalized) mantissae has more than 
d + 1 (d = number of significant digits in the mantissa of the representa- 
tion) leading zeros, the product will be zero. No error indication occurs 
in this instance „ 

If overflow occurs the characteristic is set to the largest value 
possible and an overflow indicator is set. 
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2.1 Flow Diagram 

2.1.1 Flow Chart 
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2.1.2 Process Graph 
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2.2 Other 

We have assumed that the floating point representation is of a 
particular form, i.e,, the mantissa normalized between e * and 1 . 

Other normalizations are possible, in particular the mantissa might be 
normalized between 1 and $ . In this instance the procedure for norma- 
lization might involve a right shift rather than a left shift. 

Another slight difference which can occur is the bias of the 
characteristic. In order to avoid storing negative characteristics, the 
value stored is biased by a positive integer, a . If M represents the 
maximum value which can be represented by the digits allowed for the 
characteristic, the approximate range of numbers which can be represented 

— f* JVi ■“ r* 

is g to 3 . Hence, cr. is often chosen to be near M/2 . In any 

case, if a / 0 the bias must be allowed for when computing the charac- 
teristic of the product . 

2 .3 References 
None 
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V. Floating Point Addition 

1 .0 Background Information and General Description 

The purpose of this algorithm is to obtain the sum of numbers 
represented in floating point format on a computer which does not have 
floating point hardware. It is assumed the computer can perform fixed 
point additions „ 

1.1 Other Algorithms Used 
None 

1.2 Input Values 

The input values are the two operands expressed in floating point 

format . 

1 0 3 Output Values and Accuracy 

The output value is the sum of the two input values, expressed 

in normalized floating point format. The output value is accurate to + | 
th 

in the d ' (least) significant digit provided the input values are in norma- 
lized form. Unnormalized input values may result in less accuracy. Under- 
flows (number too small to be represented) result in the output value being 
set to zero, while overflows (number too large to be represented) result in 
the output value being set to the largest number which can be represented, 
with the appropriate sign. 

1.4 Operation Count 

The operation count depends on the instruction repertoire of the 
computer, but will involve between 3 and 3 + d additions, between 5 and 
5 + d tests, and a similar number of shifts . All but two of the additions 
can be performed as index increments . At least five logical operations 
will be required . 

1.5 Memory Requirements 

The algorithm requires about ten locations for temporary storage 



and constants . 



2 .0 Mathematical and Natural Language Description 

Let A and B be represented in floating point form. Define A 

a -1 m 

and a such that A - A g , where » < A < 1 or A = 0 . Here 

m mm 

p is the base of the number system used by the computer. B and b 

m 

are defined analogously. Let T be the number with larger exponent, or 

either one if they have the same exponent., and let S be the other. Define 

T , t , S and s as above. Then s st and the tentative, unrounded, 
m m s - t 

mantissa of A + B is R = T + S ff . IfR=0,C=A+B=0. 

m m 

Otherwise [r| is normalized, rounded to d digits, and renormalized 
if necessary. The characteristic of the sum is adjusted as J R j is nor- 
malized, then tested for underflow or overflow. On underflow, the output 
value is set to zero, on overflow the output value is set to the largest 
number which can be represented . Finally the appropriate sign is attached 
to the (nonzero) result . 
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2.1 

2 . 1.1 



Flow Diagram 
Flow Chart 
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2.2 Other 

Floating point number representations different than that assumed 
are possible, e.g. the mantissa normalized to lie between 1 and 0 . 

In this instance the tests for normalization may be slightly different. 

2.3 References 
None 
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VI. Floating Point Compare 

1.0 Background Information and General Description 

The purpose of this algorithm is to compare two numbers expressed 
in floating point format and determine if they are equal , or which is larger 
if they are not equal . 

1.1 Other Algorithms Used 
None 

1.2 Input Values 

The input values are the two numbers A and B in normalized 
floating point form , 

1.3 Output Values and Accuracy 

The output value is an integer which Lakes on the following 

values: 

0 if A = B 

1 if A > B 
-1 if A < B 
■unt 

The algorithm may include as many as 4 tests , 5 logical operations , 
and a number of load and store instructions . 

1.5 Memory Requirements 

Two constants are required and up to four temporary storage lo- 
cations , depending of the number of registers and whether they must be saved. 
2 .0 Mathematical and Natural Language Description 

Let A and B be represented in normalized floating point form. 

3 . ”1 

Define A = A g where g s A < 1 or A - 0 and e is the base 
m mm 

of the number system used by the computer. B and b are analogously 
defined. If A and B have opposite sign bits, then r = 1 or -1 as 
A £ 0 or A > 0 , respectively. When they have the same sign, the 
characteristics are compared and r = ^ or as a > b or a < b , 



r = 



1.4 Operation Co 
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where c = ! or -1 as A is nonnegative or negative, respectively. If 

a = b , the rnantissae are compared and r = 1 , 0 , or -1 as A > B , 

m m 

A = B , or A < B , respectively, 
mm mm 
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2.1 Flow Diagram 

2.1.1 Flow Chart 
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2 .2 Other 
None 

2.3 References 



None 



VII. Memory Rotate 

1.0 Background Information and General Discussion 

The purpose of this algorithm is to rotate the contents of a 
table in memory an arbitrary number of places . 

1.1 Other Algorithms Used 

None 

1.2 Input Values 

The input values are the tabular array, the number of entries in 
the table, n , and the number of places through which the table is to be 
rotated, r . It is assumed that 0 < r < n . If r is outside this range 
an error may occur. No errors are indicated when this occurs, however. 

1.3 Output Values and Accuracy 

The output values are the rotated tabular array. There are no 
error indications . 

1 .4 Operation Count 

There are principally three types of operations involved: 

(1) index incrementation, of which there are between 2n + 3 and 
3n + 3; (2) tests , of which there are between n + 3 and 2ri + 3; 

and (3) load, store, and register exchange, of which there are about 
n each . The total number of operations will depend on the number of 
registers available. 

1.5 Memory Requirements 

No more than five temporary storage locations should be 



required . 

2 .0 Mathematical and Natural Language Description 
Let the table entries >: 



o 



,x , be stored in memory loca- 
n-1 



tions t , l + 1 , i + 2 , i + n-1 . Then the algorithm performs the 

permutation resulting in C( H j) = x , where j = ( i + r) mod n , 
i = 0,2,..., n-1 . Here C(k) indicates the contents of location k . 
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2.1 Flow Diagram 

2.1.1 Flow Chart 
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2 .2 Other 
None 

2.3 References 
None 



4 .0 Afterthoughts 

Some difficulties remain which must ultimately be resolved, and 
there are related problems which have not been discussed. 

In some instances the number system used by the computer may 
very drastically affect the algorithm for performing certain functions. 

At this point it is no longer possible to keep the algorithm independent 
of the machine architecture. Perhaps these very basic algorithms 
should be considered to be essentially a part of the computer and not 
documented in the same fashion as higher level algorithms . The 
floating point algorithms are very near to low level algorithms in that 
sense . 

In a hierarchy of algorithms some uniform system of handling errors 
must be used, particularly in instances where there must be no crashes, 
that is, some reasonable recovery must be made from all errors . This 
subject has not been discussed previously, but it seems to the writer 
that error recovery must be handled at a point as near to the discovery 
of the error as possible. Related problems are multiple errors, and 
the problem of re-initialization if an error occurs part way through a 
computation . That is , if an algorithm updates variables , the old 
value must not be lost until it is certain the calculation can be completed . 

The problem of how to specify recursive functions has not been ex- 
plored, but must be considered. Likewise the problem of partitioning a 
large system into algorithms which will be useful to other systems (or 
already used by other systems) must be considered and solved. 

The weakest link in any specification is likely to be the individu- 
ality exhibited by the person writing the specification. 'Favorite' 
algorithms are likely to be given much better treatment than algorithms 
which are understood poorly, or disliked by the author. In other in- 
stances , algorithms thoroughly understood by the specifier may be poorly 
written because they are so 'simple' . 
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Those tendencies can only be overcome by very stringent 
guidelines on the specification, certainly more stringent than those 
proposed in Section 2.1. 
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